I'd recommend having a utility method to verify the complete output. Something like:

ValidateOutput("list", "No WSLA sessions found.\r\n");

For instance. That would make writing future tests easier

(Same for below tests)

GetBasePath() won't work here since it will look up the current process's executable folder.

To get the installation folder where wsladiag.exe is, use : wsl::windows::common::wslutil::GetMsiPackagePath()

I would recommend against this, because the service API might return that, and in that case we wouldn't want to show the usage.

To show command line parsing errors, I would recommend using something similar to this:

For the user errors to work, we'd need to explicitely enable them, like this:

    wsl::windows::common::EnableContextualizedErrors(false);

And then create an execution context that we initialize in main (probably with new entrypoint value for wsladiag):

wsl::windows::common::ExecutionContext context{Context::WslaDiag};

Then we can use context to actually get the error string when an exception is thrown

This is specific to WSL and isn't needed for WSLA tests

Same for LxsstuUninitialize(FALSE); below

Sorry if I was unclear in my previous comment. What I was suggesting was to have a method that takes the expected output as a parameter and do the validation. Something like:

void ValidateWslaDiagOutput(const std::string& Cmd, const std::string& ExpectedOutput);

So we can something like:

ValidateWslaDiagOutput("list", "<expected output>");

I'd recommend validating that the error code is 1 explicitly, since that's what we expect

nit: context is always set to the same value, so it doesn't need to be an std::optional

nit: I'd recommend validating both fds separately. For instance error messages should always be on stderr, not stdout

Same here, I'd recommend having two parameters, one for each output so we can validate them separately.

I'll also recommend validating the entire strings, that way we'll catch if anything unexpected is printed

The test class uses WSL_TEST_CLASS macro which doesn't include wsladiag.exe in the BinaryUnderTest property list. While wslaservice.exe is included (which wsladiag depends on), the test is directly executing wsladiag.exe and should declare it as a binary under test. Consider adding a TEST_CLASS_PROPERTY for wsladiag.exe after the WSL_TEST_CLASS macro, similar to how other test classes declare their specific binaries.

The comment states "Skip 'wsladiag.exe shell'" but the startIndex of 2 actually means the parser will skip the first 2 arguments (indices 0 and 1), which are "wsladiag.exe" (index 0) and "shell" (index 1). The comment is correct in intent but could be clearer. Consider rephrasing to "Skip first 2 args (wsladiag.exe, shell) to parse shell-specific args" to be more explicit about what startIndex=2 means.

Using early return (no else block if there's a return in 'if' block) pattern here might be better for readability and reduced indentation

We should do a wslutil::PrintMessage here and return 1

The usage string could be made into a const std::string or a constexpr std::string_view. Then you can use that in the ValidateUsage() method in the WsladiagTests to verify if Usage string was returned as expected by the help case or an error case.